Software development is typically performed as group projects. A subject software system is developed through design efforts, test efforts, implementation efforts and maintenance efforts. There may be different groups and different group members participating in each of these efforts. Throughout these efforts and among the work group members, various modeling and other development tools are used for increased communication and consistency in developing the subject software system. A software configuration management system is one such tool.
Software configuration management systems provide an interface for users (software developer/engineer) to work with artifacts of a subject software system. An “artifact” is the persistent result of work done by a user, typically persisted in a file system such as a model and source code.
When a software development artifact is modified, the developer would like to know what other artifacts need to be modified in order for the subject system to remain consistent. Being able to perform impact analysis before changing an artifact has been a longstanding (but elusive) need in software development for years. One of the main issues is managing change to software/system requirements. Without the ability to perform impact analysis, artifacts produced as part of the development process drift apart and become inconsistent. This leads to misunderstandings, wasted time, schedule slips and non-conformance to requirements. In short, failure to manage change leads to higher development costs.
For example, when two software artifacts are connected by a dependency traceability relationship, a change to the first artifact might require a change to the second artifact in order to maintain the semantics of that relationship. These dependency traceability relationships are an essential mechanism for determining impact analysis, i.e., determining what other artifacts need to be updated following a change to a given set of artifacts. When the artifacts are placed under version control, many different configurations of those artifact versions are maintained, and changes occur in parallel in a variety of those configurations. When changes from one configuration are merged into another configuration, it appears that all of the dependency traceability relationships to the updated artifacts are suspect, i.e., have to be inspected to see if changes are required, even if the originator of those changes has verified that in fact all of these traceability relationships are valid.
Traditional solutions attempt to solve the problem using manually created and maintained traceability links. Links are manual because the variety of artifact types spans domains: for example, requirements are human readable while code is written in a formal technical language. Complex software systems have hundreds, if not thousands of requirements, and there are many to many relationships between artifact types: requirements, needs, designs, tests, code, etc.
Past attempts to maintain the validity of the traceability relationships fail because the cost to the development team outweighs the benefit. Maintaining the validity of traceability links is an arduous task even for a relatively small development effort and this is one of the main reasons existing traceability solutions fail. There are many accounts that document this issue and the difficulty in solving it.